home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Libris Britannia 4
/
science library(b).zip
/
science library(b)
/
INFO
/
PCCDEMO.ZIP
/
COMP1.EXE
/
JPEG.PRS
< prev
next >
Wrap
Text File
|
1993-12-20
|
22KB
|
353 lines
ôçä àöïï Åêéôöæä Äì ëÅäå ╬╠╬╠╬╠╧╧╬╠╡
σΣα≤⌠±Σ α±≤ΦΓδΣ
│ ûçÇô êÆ ëÅäå?
┌┐ │
└┘ │ JPEG (pronounced "jay-peg") is
┌┐┌────┐┌────┐┌────┐ │ a standardized image compression
│││ ┌┐ ││ ── ││ ┌┐ │ │ mechanism.
│││ └┘ ││ ───┤│ └┘ │ │ JPEG stands for Joint
│││ ┌──┘└────┘├── │ │ Photographic Experts Group, the
││└─┘ └────┘ │ original name of the committee
││ ß√ ≤ε∞ δαφΣ │ that wrote the standard.
┌┘│ Organizer │
│ │ Independent │ JPEG is designed for
└─┘ JPEG Group │ compressing either full-color or
│ gray-scale images of natural,
│ real-world scenes. It works well
" ÷τΣφ α Θ∩Σµ σΦδΣ Φ≥ ∞απΣ σ±ε∞ │ on photographs, naturalistic
σ⌠δδ-Γεδε± πα≤α, ≤τΣ Θ∩Σµ ÷Φδδ │ artwork, and similar material;
≤√∩ΦΓαδδ√ ßΣ α σαΓ≤ε± εσ σε⌠± ε± │ not so well on lettering, simple
σΦ⌡Σ ≥∞αδδΣ± ≤ταφ α µΦσ σΦδΣ ∞απΣ │ cartoons, or line drawings. JPEG
σ±ε∞ ≤τΣ ≥α∞Σ πα≤α. " │ handles only still images, but
│ there is a related standard
called MPEG for motion pictures. │ JPEG may be a problem for you,
│ even if they are invisible to the
JPEG is "lossy," meaning that │ eye.
the decompressed image isn't │
quite the same as the one you │ A useful property of JPEG is
started with. (There are │ that the degree of lossiness can
lossless image compression │ be varied by adjusting
algorithms, but JPEG achieves │ compression parameters. This
much greater compression than is │ means that the image maker can
possible with lossless methods.) │ trade off file size against
JPEG is designed to exploit known │ output image quality. You can
limitations of the human eye, │ make *extremely* small files if
notably the fact that small color │ you don't mind poor quality; this
details aren't perceived as well │ is useful for applications like
as small details of light-and- │ indexing image archives.
dark. Thus, JPEG is intended for │ Conversely, if you aren't happy
compressing images that will be │ with the output quality at the
looked at by humans. If you plan │ default compression setting, you
to machine-analyze your images, │ can jack up the quality until you
the small errors introduced by │ are satisfied, and accept lesser
compression. │ to one.)
│
ûçÿ öÆä ëÅäå? │ If your viewing software
│ doesn't support JPEG directly,
There are two good reasons: to │ you'll have to convert JPEG to
make your image files smaller, │ some other format for viewing or
and to store 24-bit-per-pixel │ manipulating images. Even with a
color data instead of 8-bit-per- │ JPEG-capable viewer, it takes
pixel data. │ longer to decode and view a JPEG
│ image than to view an image of a
∞αΩΦφµ Φ∞αµΣ σΦδΣ≥ ≥∞αδδΣ± is │ simpler format such as GIF.
a big win for transmitting files │ Thus, using JPEG is essentially a
across networks and for archiving │ time/space tradeoff: you give up
libraries of images. Being able │ some time in order to store or
to compress a 2 Mbyte full-color │ transmit an image more cheaply.
file down to 100 Kbytes or so │
makes a big difference in disk │ It's worth noting that when
space and transmission time! (If │ network or phone transmission is
you are comparing GIF and JPEG, │ involved, the time savings from
the size ratio is more like four │ transferring a shorter file can
be greater than the extra time │ seem as obsolete as black-and-
needed to decompress the file. │ white MacPaint format does today.
│ Furthermore, for reasons detailed
≤τΣ ≥ΣΓεφπ σ⌠φπα∞Σφ≤αδ │ later, JPEG is far more useful
απ⌡αφ≤αµΣ εσ Θ∩Σµ Φ≥ ≤τα≤ Φ≤ │ than GIF for exchanging images
≥≤ε±Σ≥ σ⌠δδ Γεδε± Φφσε±∞α≤Φεφ: 24 │ among people with widely varying
bits/pixel (16 million colors). │ display hardware. Hence JPEG is
GIF, the other image format │ considerably more appropriate
widely used on Usenet, can only │ than GIF for use as a Usenet
store 8 bits/pixel (256 or fewer │ posting standard.
colors). GIF is reasonably well │
matched to inexpensive computer │ A lot of people are scared off
displays --- most run-of-the-mill │ by the term "lossy compression".
PCs can't display more than 256 │ But when it comes to representing
distinct colors at once. But │ real-world scenes, *no* digital
full-color hardware is getting │ image format can retain all the
cheaper all the time, and JPEG │ information that impinges on your
images look *much* better than │ eyeball. In comparison with the
GIFs on such hardware. Within a │ real-world scene, JPEG loses far
couple of years, 8-bit GIF will │ less information than GIF. The
technical meaning of "lossy" has │ without visible loss, bringing
nothing to do with this, though; │ the effective storage requirement
it refers to loss of information │ down to 1 to 2 bits/pixel. 30:1
over repeated compression cycles, │ to 50:1 compression is possible
a problem that you may or may not │ with small to moderate defects,
care about. │ while for very-low-quality
│ purposes such as previews or
çÄû ûäïï âÄäÆ ëÅäå │ archive indexes, 100:1
éÄîÅæäÆÆ êîÇåäÆ? │ compression is quite feasible.
│ An image compressed 100:1 with
Very well indeed, when working │ JPEG takes up the same space as a
with its intended type of image │ full-color one-tenth-scale
(photographs and suchlike). For │ thumbnail image, but it retains
full-color images, the │ much more detail than such a
uncompressed data is normally 24 │ thumbnail.
bits/pixel. The best known │
lossless compression methods can │ For comparison, a GIF version
compress such data about 2:1 on │ of the same image would start out
average. JPEG can typically │ by sacrificing most of the color
achieve 10:1 to 20:1 compression │ information to reduce the image
to 256 colors (8 bits/pixel). │ Because the human eye is much
This provides 3:1 compression. │ more sensitive to brightness
GIF has additional "LZW" │ variations than to hue
compression built in, but LZW │ variations, JPEG can compress hue
doesn't work very well on typical │ data more heavily than brightness
photographic data; at most you │ (gray-scale) data.
may get 5:1 compression overall, │ A gray-scale JPEG file is
and it's not at all uncommon for │ generally only about 10%-25%
LZW to be a net loss (less than │ smaller than a full-color JPEG
3:1 overall compression). │ file of similar visual quality.
When a JPEG file is made from │ But the uncompressed gray-scale
full-color data, using a quality │ data is only 8 bits/pixel, or
setting just high enough to │ one-third the size of the color
prevent visible loss, the JPEG │ data, so the calculated
will typically be a factor of │ compression ratio is much lower.
four or five smaller than a GIF │ The threshold of visible loss is
file made from the same data. │ often around 5:1 compression for
│ gray-scale images.
Gray-scale images do not │ The exact threshold at which
compress by such large factors. │ errors become visible depends on
your viewing conditions. The │ chrominance subsampling, discrete
smaller an individual pixel, the │ cosine transforms, coefficient
harder it is to see an error; so │ quantization, and Huffman or
errors are more visible on a │ arithmetic entropy coding. This
computer screen (at maybe 70 │ article's too long already, so
dots/inch) than on a high-quality │ I'm not going to say more than
color printout (300 or more │ that here.
dots/inch). Thus a higher- │
resolution image can tolerate │ ûçÇô'Æ Çïï ôçêÆ çÄÄÅïÇ ÇüÄöô
more compression ... which is │ éÄïÄöæ ÉöÇìôêÖÇôêÄì?
fortunate considering it's much │
bigger to start with. The numbers │ Most people don't have full-
quoted above are typical for │ color (24 bit per pixel) display
screen viewing. Also note that │ hardware. Typical display
the threshold of visible error │ hardware stores 8 or fewer bits
varies somewhat across images. │ per pixel, so it can display 256
│ or fewer distinct colors at a
çÄû âÄäÆ ëÅäå ûÄæè? │ time. To display a full-color
│ image, the computer must choose
The buzz-words to know are │ an appropriate set of
representative colors and map the │ algorithm is best for all images.
image into these colors. This │
process is called "color │ Since JPEG is a full-color
quantization". (This is something │ format, converting a color JPEG
of a misnomer; "color selection" │ image for display on 8-bit-or-
or "color reduction" would be a │ less hardware requires color
better term. We're stuck with │ quantization. The speed and
the standard usage though.) │ image quality of a JPEG viewer
│ running on such hardware are
Clearly, color quantization is │ largely determined by its
a lossy process. It turns out │ quantization algorithm. You'll
that for most images, the details │ see great variation in image
of the color quantization │ quality among viewers on 8-bit
algorithm have *much* more impact │ displays, much more than occurs
on the final image quality than │ on 24-bit displays.
do any errors introduced by JPEG │ On the other hand, a GIF image
itself (except at the very lowest │ has already been quantized to 256
JPEG quality settings). Making a │ or fewer colors. (A GIF *does*
good color quantization algorithm │ have a specific number of colors
is a black art, and no single │ in its palette, and the format
doesn't allow more than 256 │ Furthermore, if the maker didn't
palette entries.) GIF has the │ use a high-quality color
advantage that the image maker │ quantization algorithm, you're
precomputes the color │ out of luck --- the image is
quantization, so viewers don't │ ruined.
have to; this is one of the │
things that make GIF viewers │ For this reason, JPEG promises
faster than JPEG viewers. But │ significantly better image
this is also the *disadvantage* │ quality than GIF for all users
of GIF: you're stuck with the │ whose machines don't match the
maker's quantization. If the │ image maker's display hardware.
maker quantized to a different │ JPEG's full color image can be
number of colors than what you │ quantized to precisely match the
can display, you'll either waste │ viewer's display hardware.
display capability or have to │ Furthermore, you will be able to
quantize again to further reduce │ take advantage of future
the number of colors (which │ improvements in quantization
results in much poorer image │ algorithms (there is a lot of
quality than if you had quantized │ active research in this area), or
once from a full-color image). │ purchase better display hardware,
to get a better view of JPEG │ ±Σ∩±Σ≥Σφ≤Φφµ Φ∞αµΣ≥ Φφ α ∞αΓτΦφΣ-
images you already have. With a │ ΦφπΣ∩ΣφπΣφ≤ σα≥τΦεφ.
GIF, you're stuck forevermore │
with what was sent. │ It's sometimes thought that a
│ JPEG converted from a GIF
A growing number of people │ shouldn't require color
have better-than-8-bit display │ quantization. This is false:
hardware already: 15-bit "hi- │ even when you feed a 256-or-less-
color" PC displays, true 24-bit │ color GIF into JPEG, what comes
displays on workstations and │ out of the decompressor is not
Macintoshes, etc. For these │ 256 colors, but thousands of
people, GIF is already obsolete, │ colors. This happens because
as it cannot represent an image │ JPEG's lossiness affects each
to the full capabilities of their │ pixel a little differently, so
display. JPEG images can drive │ two pixels that started with
these displays much more │ identical colors will usually
effectively. │ come out with slightly different
│ colors. Each original color gets
Φφ ≥τε±≤, Θ∩Σµ Φ≥ αφ αδδ- │ "smeared" into a group of nearby
α±ε⌠φπ ßΣ≤≤Σ± ΓτεΦΓΣ ≤ταφ µΦσ σε± │ colors. Therefore quantization
is always required to display a │ or gray-scale, but number of
color JPEG on a colormapped │ colors just isn't a useful
display, regardless of the image │ concept for JPEG, any more than
source. │ it is for a real photograph.
│
The same effect makes it │ ûçäì ÆçÄöïâ ê öÆä ëÅäå, Çìâ
nearly meaningless to talk about │ ûçäì ÆçÄöïâ ê Æôêéè ûêôç åêà?
the number of colors used by a │
JPEG image. Even if you were to │ JPEG is *not* going to
count the number of distinct │ displace GIF entirely; for some
pixel values, different JPEG │ types of images, GIF is superior
decoders would give you different │ in image quality, file size, or
results because of roundoff error │ both. One of the first things to
differences. I occasionally see │ learn about JPEG is which kinds
posted images described as "256- │ of images to apply it to.
color JPEG". This tells me that │
the poster (a) hasn't read this │ Generally speaking, JPEG is
FAQ and (b) probably converted │ superior to GIF for storing full-
the JPEG from a GIF. │ color or gray-scale images of
JPEGs can be classified as color │ "realistic" scenes; that means
scanned photographs and similar │ visible defects. (One implication
material. Any continuous │ of this is that large single-
variation in color, such as │ color borders are quite cheap in
occurs in highlighted or shaded │ GIF files, while they are best
areas, will be represented more │ avoided in JPEG files.)
faithfully and in less space by │
JPEG than by GIF. │ Computer-drawn images (ray-
GIF does significantly better │ traced scenes, for instance)
on images with only a few │ usually fall between photographs
distinct colors, such as line │ and cartoons in terms of
drawings and simple cartoons. │ complexity. The more complex and
Not only is GIF lossless for such │ subtly rendered the image, the
images, but it often compresses │ more likely that JPEG will do
them more than JPEG can. For │ well on it. The same goes for
example, large areas of pixels │ semi-realistic artwork (fantasy
that are all *exactly* the same │ drawings and such).
color are compressed very │
efficiently indeed by GIF. JPEG │ Θ∩Σµ τα≥ α τα±π ≤Φ∞Σ ÷Φ≤τ ⌡Σ±√
can't squeeze such data as much │ ≥τα±∩ ΣπµΣ≥: a row of pure-black
as GIF does without introducing │ pixels adjacent to a row of pure-
white pixels, for example. Sharp │ 16 gray levels before JPEG is
edges tend to come out blurred │ useful for gray-scale images. It
unless you use a very high │ should also be noted that GIF is
quality setting. Edges this │ lossless for gray-scale images of
sharp are rare in scanned │ up to 256 levels, while JPEG is
photographs, but are fairly │ not.
common in GIF files: borders, │
overlaid text, etc. The │ If you have a large library of
blurriness is particularly │ GIF images, you may want to save
objectionable with text that's │ space by converting the GIFs to
only a few pixels high. If you │ JPEG. This is trickier than it
have a GIF with a lot of small- │ may seem --- even when the GIFs
size overlaid text, don't JPEG │ contain photographic images, they
it. │ are actually very poor source
│ material for JPEG, because the
Plain black-and-white (two │ images have been color-reduced.
level) images should never be │ Non-photographic images should
converted to JPEG; they violate │ generally be left in GIF form.
all of the conditions given │ Good-quality photographic GIFs
above. You need at least about │ can often be converted with no
visible quality loss, but only if │ have claimed. The quality scale
you know what you are doing and │ is purely arbitrary; it's not a
you take the time to work on each │ percentage of anything.
image individually. Otherwise │
you're likely to lose a lot of │ In fact, quality scales aren't
image quality or waste a lot of │ even standardized across JPEG
disk space ... quite possibly │ programs. The quality settings
both. See later sections. │ discussed in this article apply
│ to the free JPEG software
ûçÇô Çæä åÄÄâ "ÉöÇïêôÿ" │ described in the next edition,
ÆäôôêìåÆ àÄæ ëÅäå? │ , and to many programs based on
│ it. Other JPEG implementations,
Most JPEG compressors let you │ notably Apple's and HSI's, use
pick a file size vs. image │ completely different quality
quality tradeoff by selecting a │ scales; for instance, Apple's
quality setting. There seems to │ scale covers 0-4, not 0-100. Some
be widespread confusion about the │ programs don't even provide a
meaning of these settings. │ numeric scale,just "high"/"medium
"Quality 95" does NOT mean "keep │ /"low"-style choices.
95% of the information", as some │ (Fortunately, this doesn't
prevent different implementations │ Q 75 first; if you see defects,
from exchanging compressed files) │ then go up.
│ If the image was less than
In most cases the user's goal │ perfect quality to begin with,
is to pick the lowest quality │ you might be able to drop down to
setting, or smallest file size, │ Q 50 without objectionable
that decompresses into an image │ degradation. On the other hand,
indistinguishable from the │ you might need to go to a
original. This setting will vary │ *higher* quality setting to avoid
from one image to another and │ further loss. Q 85 to 95 is often
from one observer to another, but │ best for converting GIFs.
here are some rules of thumb. │
│ Except for experimental
For good-quality, full-color │ purposes, never go above about Q
source images, the default │ 95; using Q 100 will produce a
quality setting (Q 75) is very │ file two or three times as large
often the best choice. This │ as Q 95, but of hardly any better
setting is about the lowest you │ quality. If you see a file made
can go without expecting to see │ with Q 100, it's a pretty sure
defects in a typical image. Try │ sign that the maker didn't know
what he/she was doing. │ CONVERTING GIF IMAGE S TO JPEG?
│ DOES LOSS ACCUMULATE WITH
If you want a very small file │ REPEATED COMPRESSION AND
(say for preview or indexing │ DECOMPRESSION?
purposes) and are prepared to │ WHY ALL THE ARGUMENT ABOUT FILE
tolerate large defects, a Q │ FORMATS?
setting in the range of 5 to 10 │ HOW DO I RECOGNIZE WHICH FILE
is about right. Q 2 or so may be │ FORMAT I HAVE, AND WHAT DO I DO
amusing as "op art". │ ABOUT IT?
│ ISN'T THERE A LOSSLESS JPEG?
│ WHAT ABOUT ARITHMETIC CODING? ñ
In the next edition, we will look │
at: │
│
WHERE AND HOW CAN I GET JPEG │
SOFTWARE? │
VIEWERS, APPLICATION PROGRAMS, │
ETC., SOURCE CODE αφπ σ±ΣΣ │
Θ∩Σµ Γε∞∩±Σ≥≥ε±/πΣΓε∞∩±Σ≥≥ε±. │
WHAT ARE SOME RULES OF THUMB FOR │